回顧昨天的挑戰日誌，我們在整合流程時遇到核心技術瓶頸：n8n 無法直接呼叫本地端 Python 腳本。

這個環境限制導致「自動生成報表＋自動推播」的想法暫時卡關。這讓我們必須重新思考流程設計，如何在不改變既有核心程式邏輯的前提下，成功破關呢?

於是我們開始思考可能的替代方案：

• 方案 A：提前生成快報並自動存到雲端

每天或每週定時生成 PDF 快報，存到 Google Drive，再由 n8n 負責拉檔發送給粉絲。
優點是上線速度快，能避開即時生成的整合問題，特別適合早期驗證流程。
缺點是快報並非即時產出，靈活度略低。

最快驗證可行性、最小成本啟動，初期最佳解。

• 方案 B：Python 轉 API 服務

將本地 Python 腳本包成 Web API，讓 n8n 透過 HTTP Request 節點呼叫。
這樣 n8n 不必與本機程式共存，可獨立部署在雲端或容器中。
優點是即時生成、整合靈活；缺點是需改寫成可被網路呼叫的服務，增加少許技術成本。

適合長期發展，能實現即時推播與完整自動化。

簡而言之，方案 A 強調速度與驗證，方案 B 強調彈性與即時性。
為了快速啟動 MVP，我們選擇 方案 A 作為今日挑戰重點：
先讓報表能定時生成、自動存雲端，再逐步升級至即時推播。

起飛前的整裝準備

回顧我們的願景：
希望粉絲能透過 Email 或 LINE，定期掌握關注的資訊，實現「資料自動更新 → 自動產出 → 自動通知」

模擬實際情境：
使用者在平台上互動、選擇自己關注的主題，系統便能依據這些互動，動態生成對應的快報內容。

因此，我們決定保留互動式介面的彈性，不讓它受限於原本的 Streamlit 架構。
為了做到這點，必須將前端互動邏輯（UI 層）與生成 PDF 快報的核心邏輯（運算層）分離，
讓後者能被自動化腳本重複呼叫與再利用。

因此，我們開始進行程式架構的解構與重組：

mario_project/
│
├── app.py         # Streamlit互動邏輯(前端UI層)
├── cooe.py        # 生成 PDF 快報(核心邏輯層)
├── auto.py        # 自動化快報產生腳本(排程使用)

• Streamlit互動邏輯(前端UI層)

收集使用者互動（如選擇景點）
呼叫 core.py
在介面上動態呈現互動結果

• 生成 PDF 快報(核心邏輯層)

讀取資料（如景點、評論等）
分析內容與生成結果
回傳圖表與文字內容（不依賴 UI）

• 自動化快報產生腳本(排程使用)

直接呼叫 core.py 產生 PDF。
不需 UI，只需指定景點清單即可自動輸出

今日解鎖的新技能：

🍄 技術決策取捨：學會在「最快驗證」與「最完整實現」之間做選擇。
🍄 模組化思維：學會把「互動邏輯」與「運算核心」拆開設計，讓系統更靈活。

📓 小結：

魔法信鴿從一開始的起點到整裝起飛，今天的任務更像是一場架構思維的升級。
我們完成了 MVP 的核心骨架，讓報表生成、雲端存取與自動化流程之間，開始形成清晰的邏輯層次。

接下來，我們將透過 n8n 將自動推播的願景落地實現，讓這隻信鴿正式展翅。